Self-destructing document and e-mail messaging system

ABSTRACT

A self-destructing document or e-mail messaging system is provided that automatically destroys documents or e-mail messages at a predetermined time by attaching a “virus” to the document or e-mail message. A virus in the form of a Trojan horse is attached to file (such as an e-mail message or document) when it is created. The virus contains a portion of executable code or an executable program which instructs the computer to overwrite and/or delete the file to which the virus is attached at a desired time. Since the virus is attached to the file, it will travel with the file even when the file is copied, forwarded, or saved to disks or tape drives.

[0001] This application claims priority of U.S. Provisional ApplicationSerial No. 60/049,853, entitled Self-destructing Document and E-mailMessaging System, filed Jun. 17, 1997, the entire disclosure of which ishereby incorporated by reference.

FIELD OF THE INVENTION

[0002] The present invention relates to the field of electronicallycreated documents, including electronic mail (“e-mail”) messaging, andto the field of document retention and deletion.

BACKGROUND OF THE INVENTION

[0003] E-mail messaging systems are widely used by businesses andindividuals throughout the world. E-mail systems allow a user to sendelectronic messages to other users, and to receive electronic messagesfrom other users. An e-mail system can be configured to providemessaging services to users connected to a local area network (LAN), andcan be configured to allow users to send/receive messages to/from usersoutside the LAN via an external network such as the Internet. E-mailsystems also allow users to save, copy, and forward messages receivedover the e-mail system.

[0004] The ease with which e-mail systems allow users to save, copy, andforward messages has had the unintended consequence of hamperingdocument retention policies. Typically, a document retention policy isimplemented by a business to insure that documents generated or receivedby the business are retained for a specified period of time and thendestroyed. Moreover, different document retention periods may bespecified for different types of documents. One of the goals of adocument retention policy is to provide a systematic method forretaining and destroying documents so that the business can identifywith some certainty which classes of documents from a given time periodstill exist.

[0005] An effective document retention policy is also valuable in thecontext of litigation. In such a context it is important that a businesshas a consistent policy regarding the retention and destruction ofdocuments, and that the business implements this policy. For example, ifa business' document retention policy states that letters are to beretained for a period of three years, and if it consistently followsthis policy, it will be less vulnerable to a charge that a particular5-year-old letter was destroyed because the letter was harmful to thebusiness' litigation position. In addition, if the document retentionpolicy is not consistently followed, and only some documents from aparticular time period are discarded, it is possible that the remainingdocuments will provide an incomplete or inaccurate picture of eventsoccurring during that time.

[0006] Systems that enforce document retention policies with regard tocomputer files are well known. Typically, these systems periodicallyscan the files in the network and delete files which were created priorto a specified date. Since such systems operate on a network, however,they cannot delete files which are stored on the hard drives ofindividual computers. In order to access these files, a documentretention program must be installed on each individual computer.However, even if the document retention system is installed on eachindividual computer, the system will still be unable to delete filesthat are stored on floppy disks or other external media. Moreover, thesesystems cannot delete files which have been transferred to computersoutside of the network via e-mail. Thus, for example, files which havebeen transferred to an employee's home computer or laptop, or to a thirdparty, will not be deleted by conventional document retention systems.

SUMMARY OF THE INVENTION

[0007] In accordance with a first embodiment of the present invention, aself-destructing document and e-mail messaging system is provided thatautomatically destroys documents or e-mail messages at a predeterminedtime by attaching an executable module such as a “virus” to the documentor e-mail message.

[0008] Computer viruses are well known. Generally, a computer virus is aportion of executable code or program which attaches itself to a hostfile. For example, “appending viruses” operate by attaching themselvesto the end of a host program and causing the host program to execute thevirus code prior to execution of the host program. In contrast“prepending viruses” attach themselves to the beginning of the hostprogram. Other types of viruses are located in interior portions of thehost program. Another classes of viruses are known as “macro” viruses.These viruses are macros embedded in text documents which can beconfigured to execute whenever the document is opened, created, orsaved. Typically, the term Trojan horse is used to refer to a viruswhich remains with its host file or program, and does not travel toother files or programs.

[0009] In accordance with the first embodiment of the present invention,an executable module in the form of a Trojan horse is attached to a file(such as an e-mail message or document) when it is created. Theexecutable module contains a portion of executable code or an executableprogram which instructs the computer to overwrite and/or delete the fileto which the executable module is attached at a desired time. In thismanner, the executable module sets a limit on the lifetime of thedocument or e-mail message. Since the executable module is attached tothe file, it will travel with the file even when the file is copied,forwarded, or saved to disks or tape drives.

[0010] In accordance with a further aspect of the first embodiment ofthe invention, the executable module executes each time that a file towhich it is attached is opened. The executable module determines whethera condition precedent to file deletion has been met. If the conditionprecedent is met, the executable module instructs the computer tooverwrite the file with null data, and then to save, close or delete thefile.

[0011] In this manner, the present invention provides a number ofadvantages over prior art systems. For example, since the executablemodule is attached to the file and is executed whenever the file isopened, the system according to the present invention can enforce adocument retention policy even if the file has been stored on externalmedia such as floppy disks, or on a non-network computer. This isbecause the executable module travels with the file, and is executedwhenever, and wherever, the file is opened.

[0012] In accordance with a second embodiment of the present invention,a self destructing e-mail messaging system is provided whichautomatically attaches an executable module to each e-mail message ore-mail message attachment which is created. The executable modulecontains a portion of executable code or an executable program whichinstructs the computer to overwrite and/or delete the message (and/ormessage attachment) to which the executable module is attached at adesired time. The executable module travels with the message as themessage is transmitted to its addressee because the executable module isattached to the message. Moreover, the executable module remainsattached to the message even when the message is copied, forwarded toanother addressee, or saved to disks or other external media.

[0013] In accordance with a third embodiment of the present invention, adocument security system includes a virtual container into which one ormore digital objects are “placed.” In this regard, the term “digitalobject” is used broadly, and includes documents (such as spreadsheets,charts/graphs, word processor documents, ASCII text files, images, andother data files), programs, and anything else which can be stored on acomputer.

[0014] The document security system includes a container creator and acontainer opener. The container creator and the container opener areimplemented in one or more software programs which are executed on acomputer. The container opener allows a user to set a limit on the validlifetime of the digital objects in the container. These “lifetimecontrols” may include, for example, an expiration date, an expirationdate and time, a fixed number of times in which the document can beopened, or other limits. When the container is opened by the containeropener, the container opener checks the lifetime controls. If they arevalid, the digital objects contained within the container are accessiblefor display or execution by the user. If, however, the lifetime controlsare invalid, the container opener will immediately destroy the digitalobject.

[0015] An advantage of the document security system including thecontainer creator and the container opener is that, in certainenvironments, it provides a more robust enforcement of lifetime controlsthan a self-destructing document containing an executable module. Thisis because the ability of current word processing and spreadsheetprograms to execute an executable module varies widely from product toproduct. Therefore, for example, a self-destructing document whichincludes an executable module which is executable by Microsoft Word™will not self destruct if opened, for example, as a simple ASCII filewhich is not configured to recognize and execute the executable module.In contrast, with the document security system, the documents aresecured within a container which is opened by the container opener, andthe container opener, when used, can enforce the lifetime controlsagainst any document in the container, regardless of its type.

[0016] In accordance with a further aspect of the document securitysystem in accordance with the third embodiment of the present invention,each digital object within the container may have independent lifetimecontrols. In accordance with this feature, when a single object withinthe container expires, it can be destroyed, while the other objectsremain intact.

[0017] In accordance with still another embodiment of the documentsecurity system, the digital object is a self-destructing documentcreated in accordance with the first or second embodiments of thepresent invention.

[0018] In accordance with a still further aspect of this embodiment, thecontainer, its contents, and its lifetime controls can be securedagainst a user who wishes to subvert the security system. This securityis effected through the use of encryption technology. Specifically, thecontainer creator is configured to encrypt the objects within thecontainer, and the container opener is configured to decrypt theobjects. In this manner, if a user opens one of the objects withoututilizing the container opener, the object will be unreadable.

[0019] In accordance with a further aspect of the first and secondembodiments, the self-destructing document or e-mail message isencrypted, either by the executable module or by another utility, andthe executable module is configured to decrypt the document or e-mailmessage only if the lifetime of the document or e-mail message has notexpired.

[0020] In accordance with another embodiment of the present invention, aself-destructing document is created by embedding a plurality ofexecutable modules into a document or e-mail message, wherein eachmodule is executable by a different word processing or e-mail system.For example, a document could include a first module which is executableby a first system and a second module which is executable by a secondsystem. The document itself could be a document native to either system.In accordance with this embodiment, the lifetime controls for thedocument will be enforced regardless of whether it is opened in thefirst system or the second system.

[0021] In accordance with another embodiment of the invention, anInternet commerce system is provided which employs the virtualcontainers. In accordance with this embodiment, a party who wishes tosell an electronically transmittable product over the Internet placesthe product into a virtual container using a container creator utilitywhich encrypts the product and sets lifetime controls for the product. Apotential buyer of the product who wishes to sample the product prior topurchasing it, obtains a copy of the container along with an containeropener utility from the seller. The container opener utility allows thepotential buyer to view and use the product only until a preselectedexpiration date. The container opener does not, in this embodiment,allow the user to remove the product from the virtual container. Inaccordance with a preferred aspect of this embodiment, the product isdeleted by the container opener if the container is opened after theexpiration date. In accordance with yet another aspect of thisembodiment, if the seller receives payment for the product prior to theexpiration date, the seller will transmit a unique key to the buyer. Thecontainer opener could be configured to release the product from thecontainer upon receiving the key.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022]FIG. 1 shows an illustrative prior art environment in which thepresent invention can be implemented.

[0023] FIGS. 2(a) and 2(b) show e-mail messages in accordance with thepresent invention which include pre-pending and appending viruses,respectively.

[0024]FIG. 3 is a flow chart of an illustrative method for creating aself-destructing e-mail message in accordance with an illustrativeembodiment of the present invention.

[0025]FIG. 4 is a flow chart of a macro virus which is embedded in theself-destructing e-mail message of FIG. 3.

[0026] FIGS. 5(a) through 5(c) illustrate a graphical user interface fora self-destructing document in accordance with an embodiment of thepresent invention which is implemented for a Microsoft Excel™ document.

[0027] FIGS. 6(a) through 6(c) illustrate a graphical user interface fora self-destructing document in accordance with an embodiment of thepresent invention which is implemented for a Microsoft Word™ document.

[0028] FIGS. 7(a) through 7(e) illustrate a graphical user interface fora self-destructing e-mail message in accordance with an embodiment ofthe present invention which is implemented in Microsoft Outlook™.

[0029]FIG. 8(a) shows a document set virtual container in accordancewith an embodiment of the present invention.

[0030]FIG. 8(b) shows a virtual container proxy in accordance with anembodiment of the present invention.

[0031] FIGS. 9(a) and 9(b) show a further embodiment of the document setvirtual container of the present invention.

[0032]FIG. 10(a) shows an illustrative header format for a document setcontainer configured to hold a single document.

[0033]FIG. 10(b) shows an illustrative header format for a document setcontainer configured to hold multiple documents.

[0034]FIG. 11 illustrates a graphical user interface for a containercreator utility and a container opener utility.

[0035]FIG. 12 is an illustrative flow chart for adding a document to thedocument set container of FIG. 10(b).

[0036]FIG. 13 is an illustrative flow chart for extracting a documentfrom the document set container of FIG. 10(b).

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037]FIG. 1 shows an illustrative prior art environment in which thepresent invention can be utilized. A local area network 1 (LAN 1)includes a plurality of office computers 10.1-10.6 (hereinafter referredto collectively as computers 10) and a server 20. Each computer 10includes a respective primary storage facility 12 (such as a hard drive)and a respective secondary storage facility 14 (such as a floppy disk orCD Rom drive). The server 20 similarly includes a primary networkstorage facility 22 (such as a hard drive) and a secondary networkstorage facility 24 (such as a tape or CD Rom drive). The data on theprimary and secondary network storage facilities 22, 24 is shared inthat it can be accessed by all of the computers 10. In contrast, thedata on the primary and secondary storage facilities 12, 14 of eachcomputer 10 is private in that it is accessed only by its respectivecomputer 10. The server 20 provides Internet access to out-of-networkcomputers, such as home computer 40, via transmission lines 50. Homecomputer 40 includes a primary storage facility 42 and a secondarystorage facility 44. The LAN 1 supports an electronic mail messagingservice which allows each computer 10 to send messages within the LAN 1to other computers 10 and to send messages outside the LAN 1 to out ofnetwork computers such as home computer 40. The configuration shown inFIG. 1 is illustrative of typical LANs which are often used inbusinesses. As one of ordinary skill in the art will appreciate,however, the present invention may be implemented with a variety ofnetwork configurations. Moreover, the e-mail messaging system of thepresent invention is equally applicable to non-network applications inwhich, for example, e-mail messages are sent and received by astand-alone computer via a modem or other connection. In addition, thedocument retention and deletion features of the present invention may beimplemented on a stand-alone computer, with or without a modem or otherconnection to external computers.

[0038] Some of the document retention and destruction problems which canbe alleviated in accordance with the present invention will now beexplained with reference to the configuration of FIG. 1.

[0039] For purposes of illustration, assume that local area network 1 isinstalled in a business which has adopted a document retention policythat requires that documents which are more than two years old bedestroyed. Typically, such a document retention policy will beimplemented by installing a program on the server 20 which periodicallyscans the primary network storage facility 22, and deletes documentswhich have a creation date which is more than two years earlier than thecurrent scanning date. One of the problems with a program of this typeis that it fails to adequately account for copies of the documents whichare not stored in the network storage facilities.

[0040] For example, assume user-1 creates a document on computer 10.1,and stores it on the network storage facility 22. Then, a week later,user-1 copies the document onto the hard drive 12.1 of computer 10.1,and onto a floppy disk via the secondary storage facility 14.1.Moreover, since the document is on the primary network storage facility22, user-2, may, without the knowledge of user-1, copy the document ontoprimary storage facility 12.2 of computer 10.2, and onto another floppydisk via the secondary storage facility 14.2. In this manner, fivecopies of the document have been created, only one of which can beaccessed and deleted by the network document retention program.

[0041] The above-referenced problem is further complicated by the factthat the LAN of FIG. 1 provides electronic messaging services. As aresult, user-1 can create an e-mail message and send it outside of theLAN to computer 40 via Internet servers 30. Moreover, previously createddocument files can be inserted into e-mail messages as attachments. Thiscreates additional problems. For example, the e-mail messages and theirattachments may be sent outside of the LAN to third parties who are notaware of the business's document retention policy. In any case, even ifthe e-mail is merely sent to an employee's home computer, the homecomputer will not be accessed by the network document retention program.

[0042] Typically, enforcement of document retention policies with regardto documents which are not stored on network storage facilities requireseach employee to search each directory of their individual hard drives,as well as each of their floppy disks or other secondary storagemediums. In addition, due to the ability of the e-mail system to includedocuments as attachments to e-mail messages, older documents may behidden in recent e-mail messages, making these documents difficult toidentify and delete. The employees must also be required to search theirlaptops and home computers for business files. Moreover, even if eachemployee is diligent in performing these time-consuming tasks, therewill remain the possibility that documents continue to exist on thirdparty computers.

[0043] Another problem associated with the implementation of a documentretention policy is that conventionally, when a document is deleted froma storage medium, the document itself is not removed. Instead, thecomputer merely removes the pointer to the document which indicates thedocument's location in the storage medium. The document itself remainsin the storage medium until the computer overwrites it with anotherdocument. Consequently, for employees to insure that a document isactually deleted, they must overwrite the document with null charactersand then delete the document, further increasing the time associatedwith enforcing the document retention policy.

Executable Modules Embedded in a Document or E-Mail Message

[0044] In accordance with the present invention, a self-destructingdocument system is provided which attaches an executable module to adocument. In accordance with another embodiment of the presentinvention, a self destructing e-mail messaging system is provided whichattaches an executable module to an electronic message or messageattachments when the message or message attachment is created. Theexecutable module can be attached to the message or document in anyknown manner. For example, referring to FIG. 2, the executable modulecan be attached as a prepending virus (FIG. 2A), as an appending virus(FIG. 2B), or in any known manner. The module itself can be created inany known manner by utilizing, for example, assembly languages, higherlevel programming languages, or macros. The attached executable modulecauses the document or message to self-destruct once a predeterminedcondition is met. In this manner, the executable module sets “lifetimecontrols” which control the lifetime of the document. In theabove-referenced illustration, for example, the executable module wouldbe programmed to delete the document or message to which it is attachedif the current date was more than two years later than the creation dateof the document or message. In accordance with a further embodiment ofthe present invention, the executable module would overwrite thedocument or message to which it is attached with null characters (e.g.,all “X'”s) prior to deleting the document or message.

[0045] In accordance with further embodiments of the present invention,the overwriting and/or deleting of the document or message may bepredicated on the occurrence of other or additional conditions. Forexample, the system could be configured to overwrite and/or delete themessage or document when the document i) is closed, or ii) is opened fora second time, thereby creating a document which can be read only onetime before it is destroyed. Alternatively, the system could beconfigured to overwrite and/or delete the message or document when anattempt to copy, forward, or print the message or document is made.Moreover, the system could be configured to block any attempt to printor copy the message or document thereby creating a document which can beviewed, but not printed. These additional lifetime controls could alsobe triggered by an event, so that the print or copy block is lifted if apassword or key is input, or so that the print or copy block is imposedafter a predetermined time period or other event.

[0046] In accordance with another embodiment of the present invention,the system could allow a LAN administrator to predetermine theoverwrite/delete condition(s) so as to impose a document retentionpolicy on all system users, and on all documents or messages created bysystem users. Similarly, the system could be configured to allow eachuser to choose whether a particular document or message includes anoverwrite/delete condition. Moreover, the user could be allowed tochoose from a variety of overwrite/delete conditions. This could beimplemented, for example, through a tools menu.

[0047] An exemplary method for implementing a self-destructingelectronic document or providing a self-destructing electronic messagingsystem will now be described. While the illustrative embodimentdescribed herein is illustrated for Microsoft Word™, Microsoft Excel™,and Microsoft Outlook™ environments, one of ordinary skill in the artwill appreciate that the present invention may be implemented in avariety of environments and in a variety of ways.

[0048]FIGS. 3 and 4 illustrate the implementation of a self-destructingelectronic messaging system for Microsoft Word™ 6.0 documents. Referringto FIG. 3, at step 200, a user initiates the creation of a document ormessage on, for example, office computer 10.1 of FIG. 1. At step 220,the system creates an “AutoOpen” macro and saves the macro in the“Normal.dot” file. In accordance with the Microsoft Word™ architecture,a macro created with the title AutoOpen will execute each time a Worddocument is opened. The instructions referenced at step 220, which arewritten in the WordBasic™ programming language, are saved as an AutoOpenmacro in the normal.dot template file. Normal.dot is a template which isdesignated by the Word™ program as a storage file for global macros. Atstep 230, the normal.dot file, which includes the AutoOpen macro, iscopied to a file named “message.dot.” Then, at step 240, the AutoOpenmacro is deleted from the normal.dot file. At steps 250-260, themessage.dot file is opened and the user is prompted to insert the textof the document or message. Then, at steps 270, the message.dot file,which now includes the document or message as well as a copy of thenormal.dot file, is saved. The copy of the normal.dot file, in turn,includes the AutoOpen macro. At steps 280-290, the message.dot file isrenamed message.doc, and then sent as an electronic mail message orelectronic mail message attachment.

[0049] The electronic mail message is sent, for example, over theInternet to Home Computer 40 via LAN server 20 and Internet servers 30.The AutoOpen macro, which is embedded in the message.doc file, willexecute when the file message.doc is opened by the addressee of themessage. FIG. 4 is a flow chart for the AutoOpen macro which is embeddedin the message.doc file. At step 310, the DateSerial( ) function returnsa serial value representative of the creation date of the message as thevariable “created.” The argument for the function DateSerial is set atthe time the AutoOpen macro is created (steps 210 and 220 of FIG. 3),and has been arbitrarily indicated as Jun. 10, 1997 in FIGS. 3 and 4. Atstep 320, the Today( ) function returns a serial value representative ofthe current date as the variable “curdate”. The serial values returnedby these functions are integers between 1 and 802074, with 1corresponding to Dec. 31, 1899 and 802074 corresponding to Dec. 31,4095. At step 330, the variable “difference” is set as the differencebetween the “curdate” and “created.” Consequently, the variable“difference” is equal to the number of days which have elapsed betweenthe creation of the message.doc file and the current date in which thedocument has been opened.

[0050] Steps 340 through 360 constitute an “If, Then” Statement whichdetermines whether the time elapsed between the creation date and thecurrent date has exceeded a predetermined threshold. For purposes ofillustration, the threshold has been set at 60 days. At step 340, thevariable “difference” is compared to the value 60. If “difference” isgreater than 60, i.e., if more than 60 days have elapsed since themessage.doc file was created, then steps 350, 360, and 370 are executed.At step 350, an EditReplace.Find function is performed. This functionwill replace each character of the message.doc file with a nullcharacter (which has been arbitrarily set as “X”.) Then, at step 360,the message.doc file, which has been rewritten as a series of “X”characters equal to the number of text characters in the file, is savedand closed. In this manner, the memory locations from which themessage.doc file was retrieved are overwritten with null characters. Incontrast, if, at step 340, the variable “Difference” is less than orequal to 60, then execution jumps to step 370 and the addressee of themessage is able to freely view and edit the message.

[0051] Naturally, the macro shown in FIG. 4 can be modified to performadditional functions. For example, the macro could be modified to deletethe message.doc file after it is saved by utilizing theFileNameFromWindow$( ) function to retrieve the location of themessage.doc file at the time it is opened, and then utilizing the Killfunction to delete the file. In addition, the macro could be modified toallow the user who is opening the message.doc file to defer messagedeletion.

[0052] FIGS. 5(a) through 5(c) and Table 1, infra, show aself-destructing document system which is illustrated with regard toMicrosoft Excel™ documents. Referring to Table 1, an illustrative VisualBasic™ program for creating a self-destructing Excel document is shownwhich includes a user interface implemented for a Microsoft Windows™environment. The implementation shown utilizes the “auto_open” and“auto_close” routine supported by Microsoft Excel™. In accordance withthe illustrated embodiment, these routines are resident in a “book.xlt”template in the xlstart subdirectory of Microsoft Excel™. In thismanner, book.xlt, with the auto_open and auto_close routines, are usedas a template for each Microsoft Excel™ document that is created. Theseroutines are therefore resident in the Excel document itself.

[0053] Each time an Excel document is created, the program of Table 1 isembedded as a macro in the document. When the document is closed, theauto_close routine is implemented. After reading the variables “lcdata”and “lcmode” from the custom document properties (Table 1, lines 23-26),the program checks to see that lifetime controls have not yet been setfor the document (Table 1, line 28). If lifetime controls have alreadybeen implemented, then the auto_close routine is exited (Table 1, line29). If lifetime controls have not been implemented, then the programasks the user whether he/she wishes to implement lifetime controls (FIG.5a). If they do, then the program asks the user to input an expirationdate for the document (FIG. 5(b) and Table 1, lines 35-36). Theexpiration date is then stored as “lcdata” and “lcmode” is set to “1”(Table 1, lines 37-38). If the user does not wish to implement lifetimecontrols, then “lcmode” is set to “0” and “lcdata” is set to “ ” (Table1, lines 39-41). The values of “lcmode” and “lcdata” are stored withinthe Excel™ document as custom document properties.

[0054] When an Excel™ document containing the embedded program isopened, the auto open macro (Table 1, lines 2-20) is executed. Thevalues of “lcmode” and “lcdata” are read from the custom documentproperties (Table 1, lines 4-7). If “lcmode” is equal to “1” (line 9),and the current date is after the date in “lcdata” (line 10), then thename of the document is stored in the variable “fn” (line 12), a messagestating that the document is no longer valid is displayed as a messagebox on the display screen of the computer (FIG. 5(c) and Table 1, line14), and the document is closed and deleted (lines 15-16). While theprogram of Table 1 does not overwrite the Excel document with null databefore deleting it, such a function could be easily added using, forexample, the Clear method in the Visual Basic™ programming language, asdescribed below:

[0055] If DateValue(Date)>=DateValue(lcdata) Then

[0056] Range(“A1”).Select

[0057] Range(Selection, Selection.SpecialCells(xlLastCell)).Select

[0058] Selection.Clear

[0059] ActiveWorkbook.Save

[0060]FIGS. 6a through 6 c and Tables 2(a,b) show a self-destructingdocument system which is illustrated with regard to Microsoft Word 97™documents. Referring to Tables 2(a,b), an illustrative Visual Basic™program for creating a self-destructing Word 97 document is shown whichincludes a user interface implemented for a Microsoft Windowsenvironment. The implementation shown utilizes the FileSave, andFileSaveAs macros to initiate the lifetime controls, and utilizes theAutoOpen macro to enforce the lifetime controls. In accordance with theillustrated embodiment, the program of Table 2 is embedded as a templatein the document.

[0061] Each time a Word 97™ document is created, the program of Table 2is embedded in the document. The program resides in an external documenttemplate on the author's workstation, and is copied into the newdocument by use of the AutoNew macro shown in Table 2c. This macroexecutes the function “InstallSDD”, which reads the program of Table 2from template SDD.dot and copies its contents, using the Microsoft WordOrganizer object, into the new document. Use of this method insures theembedded program is encapsulated within the document, in accordance withthis embodiment of the present invention.

[0062] When the new document is saved (FileSave or FileSaveAS, Table2b), the variable “lcmode” is read. If “lcmode” is undefined (i.e., thisis the first time the document has been saved), then the routine“pfImplementLifetimeControls” (Table 2a) is invoked, and the programasks the user whether he/she wishes to implement lifetime controls (FIG.6a, Table 2a). If they do, then the program asks the user to input anexpiration date for the document (FIG. 6(b) and Table 2a). Theexpiration date is then stored as “lcdata” and “lcmode” is set to “1”(Table 2a). If the user does not wish to implement lifetime controls,then “lcmode” is set to “0” and “lcdata” is set to “ ” (Table 2a). Thevalues of “lcmode” and “lcdata” are stored within the Word 97™ documentas document variables.

[0063] When a Word 97™ document containing the embedded program isopened, the AutoOpen macro (Table 2b) is executed. The values of“lcmode” and “lcdata” are read using the “pfGetLcmode” and “pfGetLcdata”functions (Table 2a, 2b). If “lcmode” is equal to “1” (Table 2b), andthe current date is after the date in “lcdata”, then the name of thedocument is stored in the variable doc (line 12), the variable “rng” isset to the length of the document, the document is overwritten with nulldata (ret=rng.Delete) and then deleted (Kill(dlg.name)), and a messagestating that the document is no longer valid is displayed as a messagebox on the display screen of the computer (FIG. 6(c) and Table 2b)

[0064] FIGS. 7(a) through 7(e), and Table 3 illustrate aself-destructing document system which is illustrated with regard toMicrosoft Outlook™ 98. Referring to Tables 3, an illustrative VisualBasic program for creating a self-destructing Outlook™ 98 e-mail messageis shown which includes a user interface implemented for a MicrosoftWindows environment. Referring to FIGS. 7(a) and 7(b), a tab entitled“Self-destruct” 73 is added to the default e-mail message template. FIG.7(a) shows the conventional “message” tab 74 which is displayed when auser wishes to create an e-mail message. The tab 74 includes the e-mailmessage text 76 and the address of the recipient of the e-mail 77. FIG.7(b) shows the self-destruct tab, which includes a toggle box 71 whichindicates whether the message will be a self-destructing message, and adate box 72 in which the destruction date is entered. As explainedbelow, the destruction date is embedded in the e-mail message andretrieved and processed when the e-mail message is opened.

[0065] Outlook 98 supports Outlook Items (individual objects such asmessages, calendar entries, tasks, etc.) which support Visual Basiccode. A collection of events are defined for each Item and Visual Basiccode may be written to conform to each event. In the Outlook objectmodel, an e-mail message is known as a “MailItem”. Outlook™ allows aprogrammer to intercept and modify application behaviors, and bothmessage-creation and message-opening behaviors can be intercepted andmodified.

[0066] Table 3 illustrates a Visual Basic program which is embedded inan e-mail message and which is executed whenever an e-mail message isopened by using the Item_Open function. When an e-mail message iscreated, and a check is entered in the toggle box 71 and a date isentered in the date box 72 of the self-destruct tab 73, then the valueof the toggle box 71 is stored in “Item.UserProperties(“DoDestruct”),”and the date entered in the date box 72 is stored in“Item.UserProperties(“DestructDate”).” These values are embedded in thee-mail message along with the program of Table 3. When the e-mailmessage is opened, the embedded program Function Item_Open isautomatically executed. Referring to Table 3, if the DoDestruct propertyis False (i.e., the message is not a self-destructing message), then theprogram is exited and the e-mail message is opened. However, if theDoDestruct property is True, then the program checks to see if themessage is expired by implementing the function “itemExpired,” which inturn, implements the function “daysTilDestruct.” The functiondaysTilDestruct subtracts the current date from the value of“DestructDate”, and returns the difference in days. The value returnedby the function daysTilDestruct is stored in the variable “dt” in thefunction itemExpired. If “dt” is less than or equal to zero, then thefunction “itemExpired” returns the boolean value True to the functionItem_Open, the text of the message is overwritten with the text “Thismessage is no longer available” as shown in FIG. 7(e), and the message“This message is no longer available” is displayed in a dialog box asshown in FIG. 7(d). If “dt” is greater than 1, then “itemExpired”returns the boolean value False, and the message “This message willdestruct in [daysTilDestruct] days” is displayed in a dialog box asshown in FIG. 7(c).

Tables 1 Through 3

[0067] TABLE 1 Attribute VB_Name = “Module1” Sub auto_open( ) On ErrorGoTo ehEnd: Dim lcmode As String lcmode = ActiveWorkbook.CustomDocumentProperties(“lcmode”) Dim lcdata As String lcdata= Active Workbook.CustomDocumentProperties(“lcdata”) On Error ResumeNext If lcmode = “1” Then If DateValue(Date) >= DateValue(lcdata) Then Dim fn As String fn = Active Workbook.Name Dim ret ret = MsgBox(“‘” +fn + “’ is no longer valid.”, vbCritical + vbOKOnly, “Purdue/SDD”)Active Workbook.Close (False) Kill (fn) End If End If ehEnd: End Sub Subauto_close( ) On Error GoTo ehImplement: Dim lcmode As String lcmode =ActiveWorkbook.CustomDocumentProperties(“lcmode”) Dim lcdata As Stringlcdata = ActiveWorkbook.CustomDocumentProperties(“lcdata”) On ErrorResume Next If lcmode <> “” Then Exit Sub End If ehImplement: Dim retret = MsgBox(“Would you like to implement lifetime controls in thisworkbook?”, vbQuestion + vbYesNo, “Purdue/SDD”) If ret = vbYes Thenlcdata = InputBox(“Please enter the expiration date for this workbook.”,“Purdue/SDD”, Date) ret = ActiveWorkbook.CustomDocumentProperties.Add(“lcmode”, False,msoPropertyTypeString, “1”) ret = ActiveWorkbook.CustomDocumentProperties.Add(“lcdata”, False,msoPropertyTypeString, lcdata) ElseIf ret = vbNo Then ret =ActiveWorkbook.CustomDocumentProperties.Add(“lcmode”, False,msoPropertyTypeString, “0”) ret =ActiveWorkbook.CustomDocumentProperties.Add(“lcdata”, False,msoPropertyTypeString, “”) End If End Sub

[0068] TABLE 2A Attribute VB_Name = “Utilities” Public FunctionpfGetLcmode(doc As Document) As String On Error GoTo ehUndefined Dimlcmode As String lcmode = doc.Variables(“lcmode”) pfGetLcmode = lcmodeExit Function ehUndefined: pfGetLcmode = “” End Function Public FunctionpfGetLcdata(doc As Document) As String On Error GoTo ehUndefined Dimlcdata As String lcdata = doc.Variables(“lcdata”) pfGetLcdata = lcdataExit Function ehUndefined: pfGetLcdata = “” End Function Public FunctionpfImplementLifetimeControls(doc As Document) As Boolean Dim ret ret =MsgBox(“Would you like to implement lifetime controls in thisdocument?”, vbQuestion + vbYesNo, “Purdue/SDD”) If ret = vbYes Then ret= doc.Variables.Add(“lcmode”, “1”) Dim data As String data =InputBox(“Please enter the expiration date of this document.”,“Purdue/SDD”, Date) ret = doc.Variables.Add(“lcdata”, data) ElseIf ret =vbNo Then ret = doc.Variables.Add(“lcmode”, “0”) End If pfSetLc = TrueEnd Function

[0069] TABLE 2B Sub FileSave( ) Attribute FileSave.VB_Description =“Saves the active document or template” AttributeFileSave.VB_ProcData.VB_Invoke_Func = “Normal.NewMacros.FileSave” Dimlcmode As String lcmode = pfGetLcmode(ActiveDocument) If lcmode = “”Then Dim ret As Boolean ret =pfImplementLifetimeControls(ActiveDocument) Else End IfActiveDocument.Save End Sub Sub FileSaveAs( ) AttributeFileSaveAs.VB_Description = “Saves a copy of the document in a separatefile” Attribute FileSaveAs.VB_ProcData.VB_Invoke_Func =“Normal.NewMacros.FileSaveAs” Dim lcmode As String lcmode =pfGetLcmode(ActiveDocument) If lcmode = “” Then Dim ret As Boolean ret =pfImplementLifetimeControls(ActiveDocument) Else End IfDialogs(wdDialogFileSaveAs).Show End Sub Sub AutoOpen( ) Dim doc AsDocument Set doc = ActiveDocument Dim lcmode As String lcmode =pfGetLcmode(doc) Dim lcdata As String lcdata = pfGetLcdata(doc) Iflcmode = “1” Then If DateValue(Date) >= DateValue(lcdata) Then Dim rngAs Range Set rng = doc.Content( ) ret = rng.Delete( ) doc.Close(wdSaveChanges) Kill (dlg.Name) ret = MsgBox(“This document is no longervalid.” & Chr(13) & “It has been destroyed.”, vbCritical + vbOKOnly,“Purdue/SDD”) Exit Sub End If End If End Sub

[0070] TABLE 2C Sub AutoNew( ) Call InstallSDD End Sub Sub InstallSDD( )Dim tPath As String tPath = Options.DefaultFilePath(wdUserTemplatesPath)tPath = tPath + “\SDD.dot” On Error GoTo errHandlerApplication.OrganizerCopy_(—) Source:=tPath,_(—)Destination:=ActiveDocument.Name,_(—) Name:=“SDDModule”,_(—)Object:=wdOrganizerObjectProjectItems Exit Sub errHandler: MsgBox “Couldnot load self-destructing document module.” Exit Sub End Sub

[0071] TABLE 3 Function Item_Open( ) If Item.UserProperties(“DoDestruct”).Value = False Then Item_Open = True Exit Function End IfIf itemExpired ( ) Then Item.Body = “This message is no longeravailable.” Item.Save ( ) MsgBox (“This message is no longeravailable.”) Else MsgBox (“This message will destruct in ” &daysTilDestruct ( ) & ” days.”) End If End Function Function itemExpireddt = daysTilDestruct ( ) If dt <= 0 Then itemExpired = True ElseitemExpired = False End If End Function Function daysTilDestructdaysTilDestruct = DateDiff (“d”, Now ( ), Item.UserProperties(“DestructDate”).Value) End Function

[0072] Moreover, the executable modules in accordance with theself-destructing documents set forth above can also utilize encryptiontechniques to prevent a user from defeating the lifetime controls, forexample, by opening a self-destructing document with an applicationwhich is incapable of executing the executable module. In accordancewith such an embodiment, when a document is first saved or closed, theexecutable module will encrypt the document. Then, when the document issubsequently opened, the executable module will decrypt the documentonly if the lifetime controls are valid. Moreover, if the document isopened with an application which is incapable of executing theexecutable module, then the document will remain encrypted, and the userwill be unable to view the document. As an example, if a user attemptsto open a self-destructing Microsoft Word™ document using theWordPerfect™ application, the WordPerfect™ application will not executethe Microsoft Word™ AutoOpen or File Open macro, and the document willbe opened regardless of whether the lifetime controls of the documentare valid. However, if the self-destructing Microsoft Word™ document hadbeen previously encrypted by the AutoClose, FileSave or FileSaveAsmacros (using, for example, an exclusive- or polyalphabetic cipher asdescribed below), then the document would remain encrypted unless theuser opened the file using an application which executes the macro(which would include the corresponding decryption algorithm for theexclusive- or polyalphabetic cipher). The selection of an appropriateencryption technique would be dependent on the degree of securitydesired, and the ability of the macro or script used to implement it.

[0073] Virtual Containers

[0074] A document security system in accordance with the presentinvention which employs virtual containers will now be described.

[0075] In accordance with a first embodiment of the document securitysystem illustrated in FIG. 8a, a document set container 500 is used tostore one or more documents 510 (or other digital objects), each withindependent lifetime controls 520. A utility is installed on anycomputer where a user wishes to open and display the contents of thecontainer. That utility validates the lifetime controls of a documentbefore displaying it to the user. If the lifetime controls are valid,then the document is extracted from the container is available for useby the user. If the lifetime controls are invalid, the document isdestroyed by, for example, overwriting the document with null data.

[0076] In accordance with a second embodiment of the document securitysystem shown in FIG. 8(b), a container proxy 500′ can be used to store asingle document 510′ (or other digital object). A proxy handler isinstalled on any computer where a user wishes to open and display thedocument in the proxy container. Unlike a document set container, theoperation of a proxy is invisible to the user—unless the document'slifetime controls 520′ are invalid. In order to provide thistransparency, the proxy is named or otherwise encoded to appear as anormal instance of a document, and the operating system mechanism thatassociates documents with their applications is altered to associate thedocument with the proxy handler instead. The proxy handler willtransitively complete the association between the document and theapplication if the lifetime controls are valid. This embodiment takesadvantage of the fact that when a file is accessed, for example byclicking with a mouse on a file from a Windows 95™ desktop, from aWindows 95 document icon in “My Computer”, or from the file manager inWindows 3.1, the operating system will attempt to associate the filewith an application, such as Microsoft™ Word, Microsoft Excel™, orWordPerfect™. In accordance with the container proxy, the containerproxy utility is interposed between the operating system and theapplication, so that when a user accesses a container proxy (which willappear to the user as an ordinary document), the operating system willinvoke the container opener to automatically open the container and, ifthe lifetime controls are valid, will start the application and open thedocument in the container. If the lifetime controls are invalid, thedocument is destroyed by, for example, overwriting the document withnull data and/or deleting the document. In accordance with furtherembodiments of the container proxy, the system can be configured toautomatically return the document to the container proxy when theapplication is closed.

[0077] Various embodiments of the document set container (DS container)will now be discussed. In accordance with a first embodiment of the DScontainer, a container opener utility and a container creator utilityare provided. The container creator utility resides on the computer of auser who wishes to create a DS container, and, as its name suggests, isoperable to create a DS container, to specify lifetime controls, and toplace a document in the DS container. The container opener utilityresides on the computer of a user who wishes to open a DS container, andis operable to open the DS container, to check the validity of thelifetime controls, and to extract the document from the DS container ifthe lifetime controls are valid. If the lifetime controls are invalid,the document is destroyed by, for example, overwriting the document withnull data. In accordance with one embodiment, the DS container containsonly one document. In accordance with further embodiments, multipledocuments can be stored in a single container, and each document mayhave its own lifetime controls. In situations in which it is desirableto allow a user to open, but not create, a DS container, the containeropener utility can be installed on a computer without the containercreator utility. Regardless of the number of documents which reside inthe DS container, an unopened DS container appears to a user as a singlefile, and includes header information (including, for example, thelifetime controls) as well as the document or documents themselves.

[0078] In accordance with a further aspect of the multiple document DScontainer in accordance with the present invention, the DS container mayinclude a container header, which contains control information for thecontainer, and which refers to two singly-linked lists of streams. Thefirst linked list contains active streams, and the second containsinactive streams. Active streams correspond to documents which stillhave valid lifetime controls and inactive streams correspond todocuments which have invalid lifetime controls, or which have beenremoved (deleted) from the container. Both active and inactive streamshave headers that contain lifetime control (and preferably encryptioninformation as described below) for their corresponding streams. Thesestream headers each contain a reference to the next stream in its list(whether active or inactive), or an indicator that this stream is thelast in its list. Each stream is a contiguous block of binary data.

[0079] When a stream is invalidated or is removed from the container,its stream header is marked as inactive, moved to the inactive streamlist, and the stream itself is overwritten with null data. When a newstream is added to the container, an inactive stream can be reactivatedand used if it is of sufficient length to contain the new stream. If noinactive stream is available or sufficient to contain the new stream, anew stream can be created and activated in the container. If a containerexperiences many changes to the active and inactive stream lists, it maybecome fragmented. In other words, as documents expire and are replacedwith null data, the active documents may be sandwiched between one ormore inactive documents which simply comprise null data. In a preferredembodiment of the invention, the container creator utility can detectthis condition and compact the container when required.

[0080] FIGS. 9(a) and (b) illustrate the active/inactive streamembodiment of the present invention. FIG. 9(a) shows a virtual containerwhich has been created with three documents contained therein. As shownin FIG. 9(a), the container header includes creation information (suchas the name of the container, the default lifetime controls for thecontainer, the date the container was created, the date the containerwas last modified DM 804, and the date the container was last accessed),information regarding the active stream (such as a pointer to the firstdocument in the active stream and the number of documents in the activestream), and information regarding the inactive stream (such as apointer to the first document in the inactive stream and the number ofdocuments in the inactive stream). Each document in the containerincludes a document header including lifetime control information and apointer to the next document in its respective stream. Since thecontainer has just been created, all three documents are in the activestream, and the container header includes an active stream sub-headerwhich includes a pointer to the first document and an indication thatthree documents are in the active stream. The inactive stream sub-headerincludes null information. Then, in FIG. 9(b), two new documents(documents 4 and 5) have been added to the container, and document 2 hasexpired. While the active stream container sub-header still points todocument 1, the pointer in the document 1 header now points to document3 instead of document 2. Moreover, the inactive stream containersub-header now points to document 2.

[0081] As set forth above, a virtual container in accordance with thepresent invention contains one or more documents that should bedestroyed when they are no longer valid (as determined by their lifetimecontrols). In general, the cost of the effort needed to defeat thesecontrols should exceed the value of extending the valid life of thedocuments.

[0082] In accordance with a preferred embodiment of the presentinvention, the documents within the virtual container are encrypted inorder to prevent unauthorized access to a document in the container, andto prevent a user from defeating the lifetime controls for a document.These encryption techniques can be used, for example, with any of thevirtual containers described herein, including the DS containers ofFIGS. 8a, 9 a, and 9 b, and the proxy containers of FIG. 8b.

[0083] In accordance with a further embodiment of the present invention,the system allows an author to select from several levels of security,based on the perceived value of the documents contained within. Ingeneral, as the level of security increases, so does the effort requiredto defeat it—and so does the cost and complexity of the security itself.Before describing how encryption can be used in the virtual container,some basic principles of encryption technology will be discussed.

An Overview of Encryption Technologies

[0084] In general, encryption technologies—which are formally calledcryptosystems—are composed of two fundamental components: the algorithmand the keys. The algorithm is a mathematical function that transformsdata. The keys “direct” the exact nature of the transformation.

[0085] Encryption algorithms can either be open or closed. Openalgorithms are published by their designers, peer reviewed by academia,and vetted through commercial implementations. Closed algorithms areproprietary works that the designers don't want the public to understandor use. In general, the encryption algorithms used in commercialproducts are “open” algorithms. An encryption algorithm which has beenpublished, reviewed, and remained in use after being widely implementedfor a long period of time can generally be considered a secure algorithmbecause it has presumably been dissected by major research universitiesand attacked by computer science students around the world without itbeing compromised.

[0086] The strength of an effective cryptosystem is generally derivedfrom its keys. Assuming that the encryption algorithm is sound (asdiscussed above), the security of the cryptosystem relies on thecreation of appropriate keys, and the careful guarding of their secrecy.One important measure of appropriateness is the length of akey—typically denoted in bits. A short key facilitates rapid encryptionand decryption, but encrypted messages are easier to break. A long keyrequires lengthy encryption and decryption processes, but may beessentially impossible to break. This perception is so pervasive thatthe U.S. Government allows the free and open use of any encryptionalgorithm, but applies strict limits to the length of the keys.

[0087] While a variety of open and closed encryption techniques can beused in accordance with the present invention, a brief discussion offour encryption technologies will be provided herein: symmetricalgorithms, public-key algorithms, digital signatures, and one-wayhashes.

[0088] Symmetric algorithms generally rely on a single key to encryptand decrypt a message. These algorithms can be simple to understand anduse, and provide a relatively high level of security if used properly.However, both parties must agree on the key before communicating,without accidentally divulging the key to any other party. Moreover, thekey must be kept secret forever, or older messages can be decrypted at alater date. Symmetric algorithms are particularly appropriate fortransient messages—messages that aren't saved after communication iscomplete. If the message isn't saved, there is no opportunity to decryptthe message later, should the key be compromised. A popular symmetricalgorithm is the Data Encryption Standard, which is an ANSI and ISOstandard, and has been in use for over twenty years.

[0089] Public-key algorithms use a pair of keys—one called the publickey and one called the private key. Either the public or the private keycan be used to encrypt a message, and the other key is used to decryptthat message. Only the private key can decrypt a message encrypted bythe public key, and only the public key can decrypt a message encryptedby the private key. Moreover, it is essentially impossible to devise analternate private key, given the public key. Typically, the public keyof any pair is published in some well-known, trusted, location (perhapsa database or directory on the Internet), while the owner retains theprivate key. A common scenario which is appropriate for public keyencryption is as follows: Alice would like to send Bob a secret message.Alice can acquire Bob's public key from a trusted source. She uses thatkey to encrypt her message to Bob. When Bob receives the encryptedmessage, he can decrypt it using his private key. If a) Alice hasacquired Bob's authentic public key (and not a forgery), and b) Bob isthe only holder of his private key (no one has a copy of it), then Aliceis guaranteed that only Bob can read her message. A popular public-keyalgorithm is the RSA Cryptosystem, owned by RSA Data Security, Inc.

[0090] Digital signatures are designed to authenticate the identity of amessage's author. Although there are many ways to implement digitalsignatures, public key encryption is very common. We can extend thescenario discussed above as follows. Alice would like to send Bob aprivate message, and she would like him to be assured that it is fromher. After all, the previous scenario doesn't guarantee that Bobreceived the message from Alice; it only assured Alice that her secretmessage to Bob was unreadable by anyone else. So, Alice first encryptsthe message to Bob with her private key. Then, she encrypts that(already encrypted) message again using his public key, as above. WhenBob receives the message, he first decrypts it using his private key.Then, to assure that the message is really from Alice, he acquires herpublic key from a trusted source. He uses that key to decrypt hermessage. If a) Bob is confident that Alice's keys haven't beencompromised through copy or forgery (as discussed above for Bob), and b)Alice is confident that Bob's keys haven't been compromised, then Aliceis still guaranteed that only Bob can read her message and Bob isguaranteed that the message is from Alice. RSA Data Security, Inc.produces a widely-used digital signature algorithm.

[0091] While digital signatures are a reliable way to prove identity inthe digital realm, there are certain instances in which authorship of adocument should be proved without requiring transfer of the entire(potentially large) document. One-way hashes provide an excellentsolution. They are mathematical functions that transform any dataset(document or otherwise) into a small stream of binary information. Animportant property of one-way hash functions is that the functionshouldn't produce two identical hashes from two different sources.Significant academic and commercial research effort has been expended tocreate one-way hashes that preserve this property. MD5 is a well-knownone-way hash function that creates a 128-bit hash.

Application of Encryption Technology to Virtual Containers

[0092] In accordance with a preferred embodiment of the invention, thevirtual container document security system allows a user (and/or asystem administrator) to select from several levels of security. A firstlevel of security might not include any encryption of the document. Itssecurity derives from the requirement that a recipient of the containeruse the container opener to display documents. However, any one ofseveral commercially-available binary file editors can be used to openthe container itself as a single document, and thereby view the contentsof the documents. Similarly, since most word processing programs allow auser to retrieve ASCII text from documents, such programs could be usedto open the container as a single document, and view any text containedtherein.

[0093] A second level of security could be a form of symmetricencryption called an exclusive- or polyalphabetic cipher. Thisencryption algorithm is simple to implement in software, and it operatesextremely quickly. This encryption algorithm uses a single key, both toencrypt and decrypt documents. This key can be “hard-coded” into thesoftware, it can be distributed with the software and changedperiodically by the user, or it can be acquired from a trusted sourceeach time it is required. In accordance with this method, the documentis encrypted by an exclusive- or -ing the document with the key (i.e.[Document] XOR [key]=[Encrypted Document]). As an example, the containeropener and container creator utilities could include a single,“hard-coded” symmetric key for both encryption and decryption. An authorof a document encrypts the document and optionally its lifetime controlsusing the container creator. When the author wishes to distribute thedocument, he forwards the encrypted document in the virtual container.The recipient decrypts the document and its lifetime controls using thecontainer opener utility. The container opener utility checks thelifetime controls, and if valid, displays the document to the recipient.If the lifetime controls are not valid, the container opener utilitydestroys the document.

[0094] A further level of security might utilize a central authority(CA) to further insure the security of the document. In accordance witha first embodiment of a CA system, the author sends the document and itslifetime controls to the CA. The CA returns a unique identifier for thatdocument. When the author wishes to distribute the document, he forwardsthe unique identifier to the recipient. The recipient sends that uniqueidentifier to the CA to review the document. The CA checks the lifetimecontrols, and if valid, returns the document to the requester. Therequester receives and displays the document. While the use of a CAenhances security, it has the disadvantage of requiring the interventionof a central authority.

[0095] A further embodiment of the CA system utilizes one-way hashes. Inaccordance with this embodiment, the author sends the document and itslifetime controls to a CA. The CA hashes the lifetime controls, andcombines the original lifetime controls, the hashed lifetime controls,and the documents into one container. The CA encrypts that containerwith its private key and returns the package to the author. When theauthor wishes to distribute the document, he forwards the CA-signedcontainer to the recipient. The recipient opens the container with theCA's public key, and checks the lifetime controls. If they are invalid,the container is destroyed. If they are valid, it hashes them andcompares that hash against the one stored in the container. If thehashes don't match, the container is destroyed. If the hashes do match,and the lifetime controls are valid, the document is displayed.

[0096] A still further embodiment of the CA system utilizes one-wayhashes and a symmetric key. In accordance with this embodiment, theauthor sends the document and its lifetime controls to the CA. The CAcreates a unique symmetric key (hereinafter DK) and encrypts thedocument. It records the DK and a unique identifier (hereinafter DKID)for it in its database. The CA hashes the original lifetime controls,and creates a container containing the original lifetime controls, thehashed lifetime controls, the encrypted document, and the DKID. It signsthat package with its private key and returns the package to the author.When the author wishes to distribute the document, he forwards theCA-signed package. The recipient opens the package with the CA's publickey. He sends the original lifetime controls, the hashed lifetimecontrols, and the DKID to the CA. The CA checks the lifetime controls.If there are invalid, the CA stops. If they are valid, it hashes themand compares that hash against the hash received from the recipient. Ifthe hashes don't match, the CA stops. If the hashes do match, and thelifetime controls are valid, the CA returns the DK which corresponds tothe DKID to the recipient. The recipient decrypts the document with theDK, and the document is displayed.

[0097] A problem with this embodiment is that the recipient can defeatthe system by creating new lifetime controls, hashing them, and sendingthe hashed new lifetime controls to the CA with the container's originalDKID. This problem can be alleviated in accordance with a further aspectof this embodiment in which the CA creates an encrypted sub-container ofthe original lifetime controls, the hashed lifetime controls, and theDKID. The encryption key(s) (e.g. symmetric keys or a public and privatekeys) are known only to the CA. The recipient (who does not have accessto the key(s) to the subcontainer) sends the sub-container back to theCA. Then, when the CA decrypts the sub-container it can be confidentthat the lifetime controls, the hashed lifetime controls, and the DKIDretrieved from the sub-container were created and encrypted by the CA.

An Implementation of the Virtual Container in the Java™ ProgrammingLanguage

[0098] An illustrative implementation of a DS container containing onedocument, and employing an exclusive- or polyalphabetic cipher, will nowbe described in which the container creator and container openerutilities are programmed in the Java™ programming language. Thecontainer creator and creator opener are implemented using the data andfile stream classes which form part of the standard I/O package of theJava programming language. Each object of a particular stream classcorresponds to a set of contiguous bytes of memory.

[0099] A DS container in accordance with this embodiment includes acontainer header, which contains control information for the container,and a document header for the document in the container. While thisembodiment of the DS container is configured to hold only a singledocument, additional embodiments described infra are capable of holdingan unlimited number of documents. Referring to FIG. 10a, in accordancewith a preferred implementation of this single document DS containerembodiment, the container header includes the name of the containerCNAME 701, the date the container was created DC 703, the date thecontainer was last modified DM 705, the date the container was lastaccessed DLA 704, and the number of documents in the container 706(either 0 or 1). The container also includes one document 710. Thedocument has a header which includes the document name (707), thelifetime controls for the document (708), and the length of the document(709). In accordance with this embodiment, the DC 703, DM 704, and DLA705 fields allow a user to determine the date that the container wascreated, the date it was last modified, and the date it was lastaccessed, as explained below with regard to the view method of Table5(a). Naturally, the container created, last modified, and last accessedfields can be omitted from the container header if this functionality isnot desired.

[0100] Referring to Table 4(a), infra, a DS container is created byinvoking the method “public static int create(String envelopefilename),”which includes as its argument the string “envelopefilename.” If“envelopefilename” is an existing file name, or if it has a null value,an error is returned, otherwise the program proceeds to create a newcontainer. An object “fos” is defined in FileOutputStream for holdingthe destination filename “envelopefilename.” A corresponding object“dos” is defined in DataOutputStream for holding the destination datacorresponding the object “dos” (which is “envelopefilename”). Theprogram then creates the header which will be stored in theDataOutputStream object “dos”. In this regard, an object “eh” is definedin class SdeEnvelopeHeader, and the “d_name” field of the classSdeEnvelopeheader is set to the string “envelopefilename,” and the“d_created”, “d_last_modified”, and “d_last_accessed” fields are set tothe current date. Then, the method “writeTo” is invoked (Table 4(c)),which writes the container name, the container creation date, the datethe container was last modified, the date the container was lastaccessed, and the number of documents in the container (currently 0), tothe object “dos”, thereby creating the container header for the newlycreated container. In this manner, the container will appear as a singlefile bearing the name contained in the “envelope name” field.

[0101] Referring to Table 4(b), in order to add a document to acontainer, the method addDocument is invoked. The method addDocumenttakes “envelopefilename”, “documentfilename”, and “expires” asparameters. If any of the parameters are null, an error is returned. Ifthe no container named “envelopefilename” exists, the “create” method(Table 4(a)) is invoked to create a container. If no document named“documentfilename” exists, then an error is returned. Otherwise, anobject “fis” of FileInputStream is defined for the “envelopefilename”and an object “dis” of DataInputStream is defined for the datacorresponding to the “envelopefilename” (DataInputStream(fis)). In thismanner, the container named “envelopename” is opened in “fis” and “dis”.Then, a temporary container is created named “[envelopefilename].tmp.”In this regard, an object “fos” of FileOutputStream is defined for the“[envelopefilename].tmp” and an object “dos” of DataOutputStream isdefined for the data corresponding to the “envelopefilename”(DataInputStream(fos)).

[0102] In order to update the envelope header, an object “eh” ofSdeEnvelopeHeader is then created, and the contents of “dis” (which isthe container header for “envelopefilename”) is read into “eh” by themethod “readFrom” (Table 4(c)). Referring again to Table 4(b), theobjects “d_last_modified” and “d_total_documents” of classSdeEnvelopeHeader are updated, and the updated envelope header (eh) iswritten to object “dos” of DataOutputStream.

[0103] In order to update the document header, the object “file_doc” ofFile is set to the path of “documentfilename”, and the variable “length”is set to equal the length of the file located at “file_doc.” The object“fis_doc” of FileInputStream is set hold the file “documentfilename”. Anobject “dh” of SdeDocumentHeader is then created, and the “d_name” fieldof the class SdeDocumentHeader is set to the string “documentfilename”,the “d_expired” field is set to the value of the parameter “expires”,and the “d_total_bytes” field is set to the value of the variable“length”. Then, the method “writeTo” is invoked (Table 4(d)), whichwrites the document name, the expiration date, and the document lengthto the object dos, thereby creating the document header for thedocument.

[0104] Then, the document is read into the variable “ch” (intch=fis_doc.read( )), and is encrypted by performing an exclusive- orfunction on “ch.” The encrypted document is then written to the object“dos”. In this manner, the updated envelope header, the document header,and the encrypted document have been written to contiguous locations inmemory using the DataOutputStream function, and a DS containercontaining one encrypted document has been created. The originalcontainer (envelopefilename) is then deleted, and the updated container(“[envelopefilename].tmp”) is renamed “envelopefilename.” In thismanner, the container will appear as a single file bearing the namecontained in the CNAME 71 field of the container, and will include thecontainer header, the document header, and the document.

[0105] An implementation of the DS container opener will now bedescribed with regard to Tables 5(a) and 5(b). Table 5(a) illustrates aprogram for viewing the container header of a DS container created inaccordance with Tables 4(a) through 4(c). The method “view” includes twoparameters, the string “envelopename” and the PrintStream “ps”. If theneither “envelopename” or “documentfilename” are “null”, and if acontainer named “envelopename” exists, an object “fis” ofFileInputStream is defined for the “envelopefilename” and an object“dis” of DataInputStream is defined for the data corresponding to the“envelopefilename” (DataInputStream(fis)). In this manner, the containernamed “envelopename” is opened in “fis” and “dis”. An object “eh” ofSdeEnvelopeHeader is then created, and the contents of “dis” (which isthe container header for “envelopefilename”) is read into “eh” by themethod “readFrom” (Table 4(c)). Finally, the container headerinformation is printed using the method “println.”

[0106] Table 5(b) illustrates a program for opening a DS containercreated in accordance with Tables 4(a) through 4(d). The method“extractDocument” includes two parameters, the strings“envelopefilename” and “documentfilename.” If the neither “envelopename”or “documentfilename” are “null”, and if a container named“envelopename” exists, an object “fis” of FileInputStream is defined forthe “envelopefilename” and an object “dis” of DataInputStream is definedfor the data corresponding to the “envelopefilename”(DataInputStream(fis)). In this manner, the container named“envelopename” is opened in “fis” and “dis”. An object eh ofSdeEnvelopeHeader is then created, and the contents of dis in classSdeEnvelopeHeader (which is the container header for “envelopefilename”)is read into “eh” by the method readFrom (Table 4(c)). An object “eh” ofSdeDocumentHeader is then created, and the contents of “dis” in classSdeDocumentHeader (which is the document header) is read into “dh” bythe method readFrom (Table 4(c)). The field “d_name” is then comparedwith “documentname”, and if they are the same, the program proceeds tocheck the expiration date of the document “documentname.” Using the Datemethod “before”, if the date in the field “d_expires” is before thecurrent date, the variable “valid” is set to False. If not, the path ofthe document is put into an object “file_doc” of the class File.

[0107] Assuming that the document “documentname” exists, and thedocument is not expired, the object “file_doc” is set to a new path:“[documentfilename].x”, and the object “fos_doc” of FileOutputStream isset to the FileOutputStream(file_doc). In this manner, a temporary file“fos_doc” is created of the class FileOutputStream. The document is thenread, one byte at a time, into the variable “ch”. Each byte, in turn, isdecrypted by performing an XOR function on “ch”, and written to“fos_doc”. If the document doesn't exist, “fos_doc” is set to a nullvalue, and the program indicates that the file is not found. If thedocument exists, but is expired, the “valid” variable is set to FALSE.This prevents “fos_doc” from being associated with the document,prevents decryption of the document, and causes the program to indicatethat the document is expired. In order to overwrite the document inorder to destroy it, the following instructions can be inserted in Table5b: if(valid==False) { for (long l=0, l<dh.d_total_bytes; l++) { int ch= 0 fos_doc.write(ch) } }

[0108] FIGS. 11(a) and 11(b) illustrate a simple graphical userinterface that can be used to implement both the single document DScontainer described above with regard to tables 4 and 5, and themultiple document DS container described below with regard to FIGS. 12and 13. In order to create a DS container, a user clicks on the “New”button 1510. A dialog box (not shown) will then appear which will promptthe user to enter a container name. Once the container name has beenentered, a DS container will be created, and the container name willappear on the banner 1500. In FIGS. 11(a) and 11(b), the container nameis “demo.env”, and the container is stored as a file “demo.env” in the“C:\” directory. In order to add a document to a DS container, a userclicks on the “Add” button 1520. A file menu (not shown) will thenappear which will allow the user to either browse the availabledirectories for the desired document, or to enter the path and documentname directly. Once the document has been chosen, and an expiration datehas been entered in box 1540, the document will be added to thecontainer. Once the document has been successfully added to thecontainer, the name of the document, the length of the document, and theexpiration date of the document will be displayed in the box 1550.Referring to FIG. 11(b), if the container “demo.env” is opened after theexpiration date of the document “demo.txt”, the document will beautomatically overwritten with null data, and a message will appear inbox 1550 indicating that the document is expired. In order to extract adocument from the container, the document is selected by clicking on thedocument in the box 1550, and then clicking the Extract button 1530. Thedocument will then be extracted from the container and stored in adesignated directory in the computer. If a document is expired, thesystem will not allow that document to be selected in the box 1550.

[0109] As set forth above, in accordance with further embodiments of theDS container, the container can be expanded and reduced to hold multipledocuments and other digital objects. New documents (or other digitalobjects) can be added to the container, existing documents in thecontainer can be updated or deleted, and multiple containers can bemerged. Each document within the container can have independent lifetimecontrols and differing levels of security.

[0110] In order to provide this functionality, the DS container ismodeled as a virtual file system within a single file. A virtual filesystem is a unit of storage that appears as a single file to theexternal world, while its internal representation really manages manyfiles and their control information. Although virtual file systemsconventionally include hierarchical directory structures, a flat—singledirectory—structure is preferably used for the DS container. Inaccordance with the preferred embodiment of invention, DS containersupports the following operations: i) creating a new DS container; ii)adding a new document to the DS container with independent lifetimecontrols and security; iii) updating the content of an existing documentin the DS container without changing the lifetime controls or security;iv) updating the lifetime controls or security of an existing documentin the DS container; v) deleting an existing document from the DScontainer; vi) invalidating an existing document in the DS containeraccording to its lifetime controls, and deleting it from the DScontainer; and vii) destroying the DS container.

[0111] A DS container in accordance with this embodiment includes acontainer header, which contains control information for the container,and a document header for each document in the container.

[0112] Referring to FIG. 10b, in accordance with a preferredimplementation of this embodiment, the container header includes thename of the container CNAME 801, the default lifetime controls for thecontainer DLC 802, the date the container was created DC 803, the datethe container was last modified DM 804, the date the container was lastaccessed DLA 805, and the number of documents in the container 806. FIG.10(b) illustrates a DS container which includes two documents 904.1 and904.1. Each document has a header which includes the document name(901.1 or 901.2), the lifetime controls for the document (902.1 or902.2), and the length of the document (903.1 or 903.2). In accordancewith this embodiment, the DLC 802 contained in the envelope header isused as the default lifetime control when documents are added to thecontainer. The DC 803, DM 804, and DLA 805 fields allow a user todetermine the date that the container was created, and the date it waslast modified, and the date it was last accessed, by implementing aroutine similar to the view method of Table 5(a). Naturally, the defaultlifetime control, container created, last modified, and last accessedfields can be omitted from the container header if this functionality isnot desired.

[0113] Since the DS container of FIG. 10b is implemented in a similarmanner to the DS container of FIGS. 10a and Tables 4a through 5b, adetailed discussion of the manner in which this embodiment can beprogrammed will not be provided herein.

[0114] Referring to the flow chart of FIG. 12, in order to add adocument to an existing DS container, the existing DS container isopened (step 1010) and the container header (including the containername, default lifetime controls, date created, date last modified, datelast accessed, and number of documents) is read. Then, at step 1030, aheader for the new document to be added is created, including thedocument name, the lifetime controls for the document, and the documentlength. The document header and the document itself are then appended tothe end of the container (steps 1040 and 1050), the values of the lastaccessed, last modified, and total number of documents fields areupdated (step 1060), and the new values written as the new containerheader. In accordance with the flowchart of FIG. 12, the updatedcontainer overwrites the original container. This is in contrast to theembodiment of Tables 4a through 5b in which the updated container iscreated as a new file, and the original container is subsequentlydeleted. Naturally, the embodiment of FIGS. 10b and 13 could be modifiedto employ the method of Tables 4a through 5b (i.e. overwriting theoriginal container) and vice versa.

[0115] Referring to the flow chart of FIG. 13, in order to extract adocument from the DS container of FIG. 10b, the container is opened(step 1110), and the container header is read. Then, at step 1120, thedocument header for the first document in the container is read from thecontainer. At step 1130, the name of the document to be extracted iscompared to the name in the dname field 901, and if they are the same,the program proceeds to step 1140. If they are not the same, the programproceeds to step 1150. Assuming the current document name in the dnamefield is the same as the requested document, the program, at step 1140,determines whether the lifetime controls for the document are valid(e.g., whether the current date is after the expiration date). If thelifetime controls are valid, the current document is extracted. If thelifetime controls are not valid, the document is deleted. Anillustrative code segment for deleting the document is shown below,wherein the function getTotalBytes( ) retrieves the document length fromthe document header for the current document. public voidnullifyDocumentContent(SdeDocumentHeader dh) throws IOException { longbytesToNullify = dh.getTotalBytes( ); for (long l = 0; l <bytesToNullify; l++) { write(0); } }

[0116] If the current document is not the requested document, theprogram, at step 1150, skips over the current document's content, to thenext document header, or the end of the envelope. Illustrative code forimplementing this function is as follows: public voidskipDocumentContent(SdeDocumentHeader dh) throws IOException { longbytesToSkip = dh.getTotalBytes( ); for (long l = 0; l < bytesToSkip;l++) { int ch = read( ); } }

[0117] In this manner, the program reads past the current document sothat when the program returns to step 1120, it is set to read thedocument header for the next document in the container.

[0118] After the document has been extracted, the last accessed field inthe container header is updated (step 1160), and the updated containerheader overwrites the container header fields 801 through 806, (step1170) and the container is closed (step 1180).

Tables 4 Through 5(B)

[0119] TABLE 4A public static int create(String envelopefilename) { if (envelopefilename == null ) { return(CREATE_FAIL_BAD_PARAM); } if (envelopeExists(envelopefilename) ) { return(CREATE_FAIL_BAD_PARAM); }try { FileOutputStream fos = new FileOutputStream(envelopefilename);DataOutputStream dos = new DataOutputStream(fos); SdeEnvelopeHeader eh =new SdeEnvelopeHeader( ); eh.d_name = envelopefilename; eh.d_created =new Date( ); eh.d_last_modified = new Date( ); eh.d_last_accessed = newDate( ); eh.writeTo(dos); dos.flush( ); fos.close( ); }

[0120] TABLE 4B public static int addDocument( String envelopefilename,String documentfilename, Date  expires ) if ( envelopefilename == null|| documentfilename == null || expires == null) {return(ADD_FAIL_BAD_PARAM); } if ( envelopeExists(envelopefilename) ==false ) { create(envelopefilename); } if (documentExists(documentfilename) == false ) {return(ADD_FAIL_BAD_PARAM); } try { FileInputStream fis = newFileInputStream(envelopefilename); DataInputStream dis = newDataInputStream(fis); FileOutputStream fos = new FileOutputStream(envelopefilename + “.tmp”); DataOutputStream dos = newDataOutputStream(fos); SdeEnvelopeHeader eh = new SdeEnvelopeHeader( );eh.readFrom(dis); eh.d_last_modified = new Date( );eh.d_total_documents++; eh.writeTo(dos); File file_doc = newFile(documentfilename); long length = file_doc.length( );FileInputStream fis_doc = new FileInputStream(file_doc);SdeDocumentHeader dh = new SdeDocumentHeader( ); dh.d_name =documentfilename; dh.d_expires = expires; dh.d_total_bytes = length;dh.writeTo(dos); while ( true ) { int ch = fis_doc.read( ); if ( ch ==−1 ) break; ch {circumflex over ( )}= 65; dos.write(ch); }fis_doc.close( ); dos.flush( ); fos.close( ); fis.close( ); Filefile_orig = new File(envelopefilename); file_orig.delete( ); Filefile_new = new File(envelopefilename + “.tmp”);file_new.renameTo(file_orig); } catch ( IOException ioe ) {return(ADD_FAIL_IOEXCEPTION); } return(ADD_OK); }

[0121] TABLE 4C class SdeEnvelopeHeader { public String d_name = null;public Date d_created = null; public Date d_last_modified = null; publicDate d_last_accessed = null; public long d_total_documents = 0; publicboolean writeTo(DataOutputStream dos) throws IOException {dos.writeUTF(d_name); dos.writeLong(d_created.getTime( ));dos.writeLong(d_last_modified.getTime( ));dos.writeLong(d_last_accessed.getTime( ));dos.writeLong(d_total_documents); return(true); } public booleanreadFrom(DataInputStream dis) throws IOException { d_name = dis.readUTF(); long c = dis.readLong( ); d_created = new Date(c); long lm =dis.readLong( ); d_last_modified = new Date(lm); long la = dis.readLong(); d_last_accessed = new Date(la); d_total_documents = dis.readLong( );return(true); } }

[0122] TABLE 4D class SdeDocumentHeader { public String d_name = null;public Date d_expires = null; public long d_total_bytes = 0; publicboolean writeTo(DataOutputStream dos) throws IOException {dos.writeUTF(d_name); dos.writeLong(d_expires.getTime( ));dos.writeLong(d_total_bytes); return(true); } public booleanreadFrom(DataInputStream dis) throws IOException { d_name = dis.readUTF(); long e = dis.readLong( ); d_expires = new Date(e); d_total_bytes =dis.readLong( ); return(true); } }

[0123] TABLE 5A public static int VIEW_OK = 0; public static intVIEW_FAIL_BAD_PARAM = 1; public static int VIEW_FAIL_IOEXCEPTION = 2;public static int view(String envelopefilename, PrintStream ps) { if (envelopefilename == null || ps == null ) { return(VIEW_FAIL_BAD_PARAM);} if ( envelopeExists(envelopefilename) == false ) {return(EXTRACT_FAIL_BAD_PARAM); } try { FileInputStream fis = newFileInputStream(envelopefilename); DataInputStream dis = newDataInputStream(fis); SdeEnvelopeHeader eh = new SdeEnvelopeHeader( );eh.readFrom(dis); ps.println(“Envelope: ‘” + eh.d_name + “’.”);ps.println(“Created:  ” + eh.d_created.toString( )); ps.println(“Lastmodified: ” + eh.d_last_modified.toString( )); ps.println(“Lastaccessed: ” + eh.d_last_accessed.toString( )); ps.println(“Contains: ” +eh.d_total_documents + “ document(s).”); fis.close( ); } catch (IOException ioe ) { return(VIEW_FAIL_IOEXCEPTION); } return(VIEW_OK); }

[0124] TABLE 5B public static int extractDocument(Stringenvelopefilename, String documentfilename) { if ( envelopefilename ==null || documentfilename == null ) { return(EXTRACT_FAIL_BAD_PARAM); }if ( envelopeExists(envelopefilename) == false ) {return(EXTRACT_FAIL_BAD_PARAM); } boolean valid = true;int invalid_reason = EXTRACT_FAIL_UNKNOWN; try { FileInputStream fis =new FileInputStream(envelopefilename); DataInputStream dis = newDataInputStream(fis); SdeEnvelopeHeader eh = new SdeEnvelopeHeader( );eh.readFrom(dis); SdeDocumentHeader dh = new SdeDocumentHeader( );dh.readFrom(dis); if (dh.d_name.equalsIgnoreCase(documentfilename) ==false) { valid = false; invalid_reason = EXTRACT_FAIL_NOT_FOUND; } if (dh.d_expires.before(new Date( )) ) { valid = false; invalid_reason =EXTRACT_FAIL_INVALID; } File file_doc = new File(documentfilename); if(file_doc.exists( ) ) { file_doc = new File(documentfilename + “.x”); }FileOutputStream fos_doc = null; if (valid) { fos_doc = newFileOutputStream(file_doc); } for (long l = 0; l < dh.d_total_bytes;l++) { int ch = dis.read( ); if ( valid ) { ch {circumflex over ( )}=65; fos_doc.write(ch); } } if ( valid ) { fos_doc.close( ); } fis.close(); } catch ( IOException ioe ) { return(EXTRACT_FAIL_IOEXCEPTION); } if( valid ) { return(EXTRACT_OK); } else { return(invalid_reason); } }

[0125] It should be noted, however, that while the exemplary embodimentsshown above provide a Java stream-based approach to virtual containers,with a relatively simple Graphical User Interface, a simple encryptiontechnique, and lifetime controls which comprise an expiration date, itshould be noted that the invention encompasses a broad array ofadditional implementations which may be simpler or more complex. In thisregard, the user interface could comprise a more complex GUI, or couldcomprise a simple command line interface without graphics. Similarly,the virtual containers could also be implemented using the Javaserialization mechanism, or could be implemented in another languagealtogether, such as C++. The lifetime controls, moreover, could bemodified to be a function of the number of times a document has beenextracted or the number times it has been modified. Moreover, thelifetime controls can be used to convert the document to a read-onlydocument after a specified period of time or to prevent the documentfrom being copied or printed.

Internet Commerce Application of Virtual Containers

[0126] In accordance with another embodiment of the invention, anInternet commerce system is provided which employs the virtualcontainers. In accordance with this embodiment, a party who wishes tosell an electronically transmittable product over the Internet placesthe product into a virtual container using a container creator utilitywhich encrypts the product and sets lifetime controls for the product.In this regard, the seller may wish to allow a potential buyer to viewor otherwise use the product for a limited trial period, and to destroythe product after this trial period if a purchase is not made. Apotential buyer of the product who wishes to sample the product prior topurchasing it, obtains a copy of the container along with an containeropener utility from the seller. The container opener utility allows thebuyer to view or use the product while maintaining the product in thevirtual container. The container opener utility, however, can beconfigured to prevent the user from printing product (or any portionthereof), from copying the product (or any portion thereof), ormodifying the product. If the buyer attempts to view the product withoutusing the container opener, he/she will be unable to decrypt theproduct. In any event, once the lifetime controls for the product becomeinvalid (e.g. after a period of time specified by the seller), anysubsequent attempt to open the container with the container opener willresult in the destruction of the product. It should be noted that theproduct could be any form of electronic media which can be transmittedin digital form, including, for example, documents, photographs, images,and programs.

[0127] In accordance with a further aspect of this embodiment, the buyercan purchase the product prior to the expiration of the lifetimecontrols by, for example, transmitting his/her credit card informationto the seller. After receiving and/or validating the paymentinformation, the seller transmits a purchase key to the buyer. Thecontainer opener is configured to recognize the purchase key (which ispreferably unique to the particular instance of the product delivered tothat particular buyer), and to allow the buyer to extract the productfrom the container if the purchase key is valid.

Use of Software Components for Virtual Containers and EmbeddedExecutable Modules

[0128] In each of the exemplary embodiments set forth above, theself-destructing documents have been implemented in application specificprograms so that a different program was used to implement aself-destructing Word™ document than a self-destructing Excel™ document.To avoid this repetitive (re-)development process, the Self DestructingDocument, or for that matter, the Virtual Container system, can beimplemented as a software component. A software component is aneasily-reusable unit of software that typically provides one simpleservice.

[0129] The Component Object Model (COM) is the Microsoft standard forsoftware component technology. It defines a standard for packagingsoftware for easy reuse. A typical COM component contains two broadcategories of content: the functionality of the component, implementedas a set of methods (functions), and descriptive information about thecomponent and its functionality. Collectively, this content is referredto as the component's interface. It should be noted that this term isused differently than then the term “user interface.” A user interfaceis typically a graphical display of windows, menus, buttons, and thelike that allow a user to interact with the functionality of anapplication. An “interface”, however, more broadly refers to thepoint(s) of entry into a unit of software (the methods, or functions).

[0130] COM components can be used to implement user interface elements,such as buttons and lists. They can also be used to provide serviceswithout a user interface. For example, a COM component could providemathematical functions to compute sines and cosines.

[0131] Although there are subtle technical differences betweencomponents and objects, they represent two very similar concepts. Assuch, this document uses the terms interchangeably in conformance withthe idiom of the trade press and technical reference material.

[0132] Further, the term control is often used to describe a componentthat does have a user interface associated with it. In particular,Microsoft uses the term ActiveX Control to describe a special class ofCOM components that typically have user interfaces.

[0133] When a COM component is used to extend the functionality of anexisting application, the component is said to be embedded in thatapplication's document. Such a component is often referred to as anembedded object. In this regard, we note that Word 97™, Excel™, andOutlook98™ each include support for Visual Basic applications through alibrary of COM objects.

[0134] Application extensions implemented with embedded objecttechniques generally require the COM component to be installed on thedocument author's computer. Further, any user that receives a copy ofthe document must also generally have the COM component installed on hisor her computer to utilize the extended functionality.

[0135] In broad strokes, a COM component for a virtual container can beimplemented as follows.

[0136] 1. First, specify the interface for the component. The interfacedescribes each of the services offered by the component. In the case ofan SDE component, the services might include CreateEnvelope,AddDocumentToEnvelope, and ExtractDocumentFromEnvelope.

[0137] 2. Implement each of the services of the component, using aprogramming language such as C++, Java, or Visual Basic.

[0138] 3. Use the programming language's development tool to create theCOM component.

[0139] 4. Install the COM component on the user's workstation. Implementthe small amount of scripting require to invoke the component'sservices.

[0140] It should be noted, however, that the Microsoft COM componentstandard has been described herein, software components standardspromulgated by other manufacturers may also be used.

[0141] While there have been described what are presently believed to bethe preferred embodiments of the invention, those skilled in the artwill realize that changes and modifications may be made thereto withoutdeparting from the spirit of the invention. It is intended to claim allsuch modifications that fall within the scope of the invention.

What is claimed is:
 1. A method for creating a self-destructingdocument, comprising the steps of: creating an executable module whichinstructs a computer to overwrite and/or delete a document to which theexecutable module is attached; attaching the executable module to thedocument.
 2. The method according to claim 1, wherein the executablemodule is an executable code.
 3. The method according to claim 1,wherein the executable module is an executable program.
 4. The methodaccording to claim 1, wherein the executable module is a macro.
 5. Themethod according to claim 1, further comprising the step of executingthe executable module when the document is opened.
 6. A self-destructinge-mail messaging system, comprising: an executable module, theexecutable module configured to instruct a computer to delete a messageto which the executable module is attached; an e-mail messaging system,the e-mail messaging system configured to create an e-mail message andto transmit the e-mail message, the e-mail messaging system attachingthe executable module to the e-mail message prior to transmission. 7.The system according to claim 6, wherein the executable module is anexecutable code.
 8. The system according to claim 6, wherein theexecutable module is an executable program.
 9. The system according toclaim 6, wherein the executable module is a macro.
 10. The systemaccording to claim 6, wherein the executable module is configured tooverwrite the message with null characters.
 11. The system according toclaim 6, wherein the executable module is configured to instruct thecomputer to delete the e-mail message upon the occurrence of apredetermined condition.
 12. The system according to claim 11, whereinthe predetermined condition is a date.
 13. The system according to claim6, wherein the executable module is configured to execute when thee-mail message to which it is attached is opened.
 14. The systemaccording to claim 6, wherein the executable module is configured tobegin execution when the e-mail message to which it is attached isopened, the executable module deleting the message during said executionif a predetermined condition is met.
 15. The system according to claim6, wherein the e-mail message is an e-mail message attachment.
 16. Thesystem according to claim 15, wherein the executable module isconfigured to instruct the computer to delete the e-mail messageattachment upon the occurrence of a predetermined condition.
 17. Thesystem according to claim 16, wherein said predetermined condition isprinting, copying or forwarding the e-mail message.
 18. The method ofclaim 1, wherein the document is an encrypted document, and wherein theexecutable module is configured to instruct the computer to decrypt thedocument if a predetermined condition is met, and to delete the documentif the predetermined condition is not met.
 19. The method of claim 6,wherein the message is an encrypted message, and wherein the executablemodule is configured to instruct the computer to decrypt the message ifa predetermined condition is met, and to delete the message if thepredetermined condition is not met.
 20. A method for creating a virtualcontainer containing a digital object, comprising the steps of creatinga virtual container, the virtual container residing in contiguouslocations in an electronic storage media of a computer, the virtualcontainer including a header portion and a digital object portion;selecting a digital object for insertion into the virtual container;applying an encryption technique to the digital object to create anencrypted digital object; writing the encrypted digital object into thedigital object portion; selecting an expiration date for the digitalobject; writing information indicative of the expiration date into theheader portion of the virtual container.
 21. A method for extracting adocument from a virtual container, comprising the steps of readinginformation indicative of an expiration date from a header portion of avirtual container, the virtual container residing in contiguouslocations in an electronic storage media of a computer, the virtualcontainer including the header portion and a digital object portion, thedigital object portion containing an encrypted digital object;determining, based upon said information, if the electronic object isexpired; overwriting the digital object portion of the virtual containerwith null data if the electronic object is expired; and reading thedigital object from the digital object portion and applying a decryptiontechnique to the digital object if the digital object is not expired.22. A virtual container system, comprising: a container creator utility,the container creator utility creating a virtual container which residesin contiguous locations in an electronic storage media of a computer,wherein the virtual container includes a header portion and a digitalobject portion, the container opener utility receiving a digital objectselection and an expiration date selection from a user, the containercreator applying an encryption technique to the selected digital objectto create an encrypted digital object and writing the encrypted digitalobject into the digital object portion of the virtual container, thecontainer creator writing information indicative of the expiration dateinto the header portion of the virtual container; a container openerutility, the container opener utility reading the information indicativeof the expiration date from the header portion of the virtual container,the container opener determining, based upon said information, if theelectronic object is expired; the container opener overwriting thedigital object portion of the virtual container with null data if theelectronic object is expired, the container opener reading the encrypteddigital object from the digital object portion and applying a decryptiontechnique to the digital object if the digital object is not expired.23. A method for creating a virtual container and extracting a digitalobject from a virtual container, wherein the method of creating thevirtual container comprises the steps of creating a virtual container,the virtual container residing in contiguous locations in an electronicstorage media of a computer, the virtual container including a headerportion and a digital object portion; selecting a digital object forinsertion into the virtual container; applying an encryption techniqueto the digital object to create an encrypted digital object; writing theencrypted digital object into the digital object portion; selecting anexpiration date for the digital object; and writing informationindicative of the expiration date into the header portion of the virtualcontainer; and wherein the method for extracting the document from thevirtual container, comprises the steps of reading information indicativeof an expiration date from a header portion of a virtual container,determining, based upon said information, if the electronic object isexpired; overwriting the digital object portion of the virtual containerwith null data if the electronic object is expired; and reading thedigital object from the digital object portion and applying a decryptiontechnique to the digital object if the digital object is not expired.24. The method of claim 20, wherein the step of creating the virtualcontainer includes the step of creating a container header and andigital object header, the container header containing informationregarding the container including a container name, the digital objectheader containing information regarding the digital object including aname of the digital object.
 25. The method of claim 24, wherein the stepof writing information indicative of the expiration date includeswriting said information into the container header.
 26. The method ofclaim 24, wherein the step of writing information indicative of theexpiration date includes writing said information into the digitalobject header.
 27. The method of claim 24, wherein the step of selectinga digital object for insertion into the virtual container includesselecting a plurality of digital objects for insertion into the virtualcontainer; the step applying an encryption technique includes applyingthe encryption technique to each of the plurality of digital objects;the step of writing the encrypted digital object into the digital objectportion includes writing each of the encrypted digital objects into thedigital object portion; the step of selecting an expiration dateincludes selecting an expiration date for each of the plurality ofdigital objects; and the step of writing information includes writingthe information indicative of the expiration date of each one of thedigital objects into a respective digital object header.
 28. The methodof claim 23, wherein the step of creating the virtual container includesthe step of creating a container header and an digital object header,the container header containing information regarding the containerincluding a container name, the digital object header containinginformation regarding the digital object including a name of the digitalobject.
 29. The method of claim 28, wherein the step of writinginformation indicative of the expiration date includes writing saidinformation into the container header.
 30. The method of claim 28,wherein the step of writing information indicative of the expirationdate includes writing said information into the digital object header.31. The method of claim 28, wherein the step of selecting a digitalobject for insertion into the virtual container includes selecting aplurality of digital objects for insertion into the virtual container;the step applying an encryption technique includes applying theencryption technique to each of the plurality of digital objects; thestep of writing the encrypted digital object into the digital objectportion includes writing each of the encrypted digital objects into thedigital object portion; the step of selecting an expiration dateincludes selecting an expiration date for each of the plurality ofdigital objects; and the step of writing information includes writingthe information indicative of the expiration date of each one of thedigital objects into a respective digital object header.
 32. A methodfor transmitting a destructible digital object to a recipient,comprising the steps of creating a virtual container, the virtualcontainer residing in contiguous locations in an electronic storagemedia of a computer, the virtual container including a header portionand a digital object portion; selecting a digital object for insertioninto the virtual container; applying an encryption technique to thedigital object to create an encrypted digital object; writing theencrypted digital object into the digital object portion; selecting anexpiration date for the digital object; writing information indicativeof the expiration date into the header portion of the virtual container,transmitting the virtual container and a container opener utility to arecipient, wherein the container opener utility, when invoked by therecipient, reads the information indicative of the expiration date fromthe header portion of the virtual container, determines, based upon saidinformation, if the electronic object is expired, overwrites the digitalobject portion of the virtual container with null data if the electronicobject is expired, and reads the encrypted digital object from thedigital object portion and applies a decryption technique to the digitalobject if the digital object is not expired.
 33. The method of claim 32,wherein the virtual container is transmitted via the Internet.
 34. Themethod of claim 27, wherein the header portion includes the containerheader and the digital object headers, and wherein each digital objectis located adjacent to its respective digital object header in thevirtual container.
 35. The method of claim 31, wherein the headerportion includes the container header and the digital object headers,and wherein each digital object is located adjacent to its respectivedigital object header in the virtual container.
 36. The method of claim21, wherein wherein the digital object is a document.
 37. The method ofclaim 22, wherein wherein the digital object is a document.
 38. Themethod of claim 23, wherein wherein the digital object is a document.39. The method of claim 32, wherein wherein the digital object is adocument.
 40. The method of claim 21, wherein wherein the digital objectis a program.
 41. The method of claim 22, wherein wherein the digitalobject is a program.
 42. The method of claim 23, wherein wherein thedigital object is a program.
 43. The method of claim 32, wherein whereinthe digital object is a program.